Repository navigation
test(history): corrupt the index the health query plan actually reads - #7995
Conversation
The routing-health integrity case corrupted idx_requests_model and expected the health query to hit it. The query can be served by the provider, model or timestamp index, and macOS's system SQLite picks a different one than Bun's bundled SQLite, so macOS 1/4 of lane=all run 41050393474 read healthy rows. Ask EXPLAIN QUERY PLAN which index this build uses and corrupt that one.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 2 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
the
chore
|
✅ Deterministic PR hygiene checks passed. |
|
Maintainer integration (lane L1, cross-platform CI). Squash-merging into dev under the maintainer-integration exception in MAINTAINERS.md. This records the decision; it is not a self-approval. Exact head: |
) The routing-health case read the index before corrupting it and relied on PRAGMA shrink_memory to evict the cached pages. macOS's system SQLite kept them, so the read after corruption was served from cache (macOS 2/4 of lane=all run 41056253802, after #7995). Reopen the index after the pre-check so the corruption lands on a connection that has not cached it, like the other corruption cases. Co-authored-by: JUN <243035832+lidge-jun@users.noreply.github.com>
Summary
Fixes the macOS failure in manual Cross-platform CI run 41050393474 (
lane=all, devac0833bc5), macOS 1/4:request-history integrity lifecycle (#7966) > routing health marks query corruption for repair and recovers current historical evidence(tests/usage/request-history-integrity.test.ts:413). The test expected{}and received live health evidence.The test corrupts
idx_requests_modeland expects the routing-health query to read it. That query (WHERE provider = ? AND model = ? AND timestamp >= ? ORDER BY timestamp DESC) can be served by the provider, model or timestamp index. Which one the SQLite planner picks depends on the build: Bun bundles SQLite 3.53.4 on Linux and Windows, where the plan isSEARCH requests USING INDEX idx_requests_model, while macOS uses the system library. On macOS the query never touched the damaged B-tree and correctly returned healthy rows. The other corruption cases, which filter by model only, passed on the same macOS job, so the corruption mechanism itself works there.The test now asks
EXPLAIN QUERY PLANwhich index this build uses for that query shape and corrupts that index. It asserts that the plan names anidx_requests_*index, so a full-scan plan fails loudly. The probe statement is prepared and finalized; a cachedquery()statement held a table lock and made the later rebuild fail withSQLITE_LOCKED. Product code is unchanged.Verification
bun test tests/usage/request-history-integrity.test.tson Windows (Bun 1.4.4, SQLite 3.53.4): 20 pass / 0 fail.sqlite_stat1rows madeidx_requests_modelunselective so the planner picks another index, as on macOS. The previous test body then failed with the same signature as CI (- Expected -1 / + Received +6), and the new body passed.lane=alldispatch on dev after merge covers macOS. Full local suite not run: the host is shared with other test lanes.Checklist